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ABSTRACT 

This paper presents the Expert Operator’s As- 
sociate (EOA) project which studies the appli- 
cability of Expert Systems for day-to-day space 
operations. A prototype Expert System is de- 
veloped, which operates on-line with an existing 
spacecraft control system at the European Space 
Operations Centre, and functions as an “opera- 
tor’s assistant” in controlling satellites. The pro- 
totype is demonstrated using an existing real-time 
simulation model of the M ARECS-B2 telecommu- 
nication satellite. 

By developing a prototype system, it is exam- 
ined to which extent the reliability and effective- 
ness of operations can be enhanced by AI based 
support. In addition the study examines the 
questions of acquisition and representation of the 
“knowledge” for such systems, and the feasibility 
of “migration” of some (currently) ground-based 
functions into future space-borne autonomous sys- 
tems. 

1 INTRODUCTION 

Supervising a spacecraft, interpreting the teleme- 
try received, deciding about the correct on-board 
operational conditions, reasoning about proper 
corrections, and executing the appropriate control 
procedures are complex tasks for modern space- 
craft. During the launch phase of the spacecraft, 
specialists may be at hand, who know about the 
design of the various sub-systems on-board, but in 
the subsequent operational phases they will usu- 
ally not be available for immediate consultancy to 
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the operators responsible for the safe conduct in 
day-to-day monitoring and controlling the space- 
craft. 

The complexity of modern spacecraft systems, 
and the resulting high demands to the person- 
nel operating them, concerns about the poten- 
tial for human errors, and the risk of inaccessibil- 
ity of the people with appropriate expert knowl- 
edge, calls for improved methodologies and en- 
vironments providing computerised support for 
monitoring and controlling spacecrafts. 

An essential element in the development of such 
support is the transfer of parts of the knowledge 
regarding the procedures for controlling the space- 
craft and regarding the design of the spacecraft, 
from the experts who conceived them, to a system 
which can be used to assist in the work with the 
spacecraft in the operational phases. 

This has been the motivation for the Operations 
Center of the European Space Agency (ESOC) to 
define a 3 year study project, called the Expert 
Operator’s Associate (EOA) project, with the aim 
of de veloping a prototype expert system for assist- 
ing in the operation of satellites. The MARECS- 
B2 communication satellite has been chosen as an 
example case for demonstration of the prototype. 
The prototype will be demonstrated with the aid 
of ESOC’s “high fidelity” real-time MARECS- 
B2 spacecraft simulator (a software model) which 
operates in closed loop communication with the 
ground control system via simulated telemetry 
and telecommand links. 

The project is structured such that the first 
phase concentrates on constructing the basic sys- 
tem. It is here demonstrated how the operator can 
be assisted in the selection and execution of Flight 
Control Procedures (FCP), covering the situations 
where the spacecraft operates within the limits 
prescribed by the specifications of the satellite. 
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In the second phase of the project, the scope is 
extended such that some of the situations where 
the spacecraft does not operate inside these limits, 
are taken into account. It is demonstrated how 
to assist in the situations where the problem can 
be diagnosed immediately, and handled by pre- 
defined Contingency Recovery Procedures (CRP). 

Finally, several experimental extensions of the 
system are investigated. One extension is opera- 
tor assistance in the situations which cannot be 
immediately diagnosed. Another extension is ma- 
chine learning, where new knowledge (e.g. CRP ’s) 
is developed as a result of a dialogue with a space- 
craft expert, and stored in the knowledge base 
of the system . Furthermore, the question of to 
which extent control functions can be “migrated” 
from the ground to future spacecraft, and the 
question of how to “streamline” the transfer of 
knowledge from the spacecraft experts to the sys- 
tem, will be addressed. 

The prototype developed is a workstation based 
system, controlling the process of daily operations 
of the spacecraft. It works in a real-time environ- 
ment communicating with the spacecraft operator 
and the spacecraft 1 . The user interaction is facil- 
itated by a graphical user interface utilizing state 
of the art techniques such as mouse, multiple win- 
dows, and pop-up menus. 

At the time of writing, the project is near its 
completion and the paper presents the overall re- 
sults, concentrating on the knowledge representa- 
tion used, and the system architecture. In Sec- 
tion 2 the general problem domain and the exam- 
ple case is further described. Then, in Section 3 
the functionality and architecture of the prototype 
system is introduced. In Section 4, the represen- 
tation and structuring of the knowledge used by 
the system, and the expert functions is described. 
In Section 5 it is illustrated how the execution 
of Flight Procedures is implemented. Alarm pro- 
cessing is described in Section 6. Finally Section 7 
concludes and the continuation of the project is 
detailed further. 

2 THE PROBLEM 

DOMAIN AND THE EX- 
AMPLE CASE 

The operating state of orbiting spacecraft is moni- 
tored and controlled on the ground at ESA’s Euro- 
pean Space Operations Centre (ESOC) at Darm- 
stadt, W. Germany, by specialist personnel sup- 

1 via the Multiple satellite Support System (MSSS) 


ported by on-line spacecraft control computer sys- 
tems (at ESOC). These computers receive teleme- 
try data from each spacecraft, typically in near- 
real-time via ground stations in various parts of 
the world. Data from the telemetry are evaluated 
and displayed to the spacecraft controller, who in 
turn can pitiate the uplink of telecommands (via 
the ground station) to the remote satellite, from 
his computer console. 

MARECS-B2 is a geosynchronous maritime 
communications satellite, and is an interesting 
example case for an on-line Expert System to 
support spacecraft control. MARECS-B2 poses 
requirements in day-to-day operation, which are 
typical for the current generation of telecommu- 
nications satellites. The downlinked housekeeping 
telemetry data, flowing 24 hours per day, provides 
a “snapshot” of the spacecraft state in a “format” 
of several hundred “parameters” (readings of on- 
board sensors) every 19.2 seconds. 

The spacecraft control computer system for 
MARECS-B2 is the ESOC Multi-Satellite Sup- 
port System (MSSS). 

The spacecraft controller monitors only a few 
of the telemetry parameters at any time, but the 
MSSS performs automatic checks on many of the 
parameters in each new format when it has been 
received. If the checks discover that parameters 
are outside their normal operating range, or sta- 
tus, audible and visual alarms are raised, so that 
the spacecraft controller is aware of a possible 
problem and can decide what to do. 

In regular day-to-day operation, which is the 
type of activity which can be most effectively sup- 
ported by EOA, the actions of the spacecraft con- 
troller are, in principle, completely defined by a 
large manual of operations procedures known as 
the MARECS-B2 Flight Operations Plan (FOP). 
This comprises Flight Control Procedures (FCP) 
covering nominal operations, and Contingency 
Recovery Procedures (CRP) which describe the 
actions to be taken in the event of non-nominal 
cases. The existence of the FOP ensures that op- 
erations can be carried out with a high degree of 
efficiency (speed in effecting configuration changes 
which affect the end-user services provided by the 
satellite), and reliability. Both of these aspects are 
of prime importance in the provision of telecomms 
services. 

Nominal operations of the spacecraft are pre- 
planned, and a schedule is defined a few days be- 
forehand by a specialist, who selects the FCP’s re- 
quired, and defines the time at which they are to 
be performed. However, it occasionally happens 
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that during operation of the pre-planned sched- 
ule, the spacecraft exhibits some unexpected be- 
haviour. The spacecraft controller then has the 
task of selecting the appropriate CRP’s. For this, 
he may need the assistance of a specialist engi- 
neer, but the latter may be unavailable immedi- 
ately (eg. in the middle of the night). 

It also affects the complexity of the task that 
the spacecraft controller must sometimes take ac- 
count of actions and knowledge about the space- 
craft state in the past, ie. historical information. 

One of the functions of the EOA is to assist the 
spacecraft controller in choosing the right CRP’s 
in a given non-nominal situation. In many cases 
this will be possible on the basis of straightforward 
matching of the situation to correspond descrip- 
tions stored with each CRP. Thus the EOA will 
effectively speed up the selection process. How- 
ever, the situation will sometimes arise where the 
choice of CRP’s is uncertain. The study aims to 
show how the EOA can assist in the selection of 
recovery action, also in such cases. 

3 OVERVIEW OF THE 
EOA 

3,1 Functions 

The core functionality of the EO A system is to as- 
sist the spacecraft operator in nominal spacecraft 
operation. Support is given by: 

• receiving, interpreting and displaying infor- 
mation regarding the state of the satellite 

• proposing selected procedures based on the 
current operating state of the spacecraft and 
the users indication of the desired state 

• presenting the chosen procedure to the user 
in both textual and graphical form 

• preparing the various spacecraft command se- 
quences needed for the execution of the plan, 
and on acceptance from the user, sending 
them to the MSSS. 

• receiving and evaluating reports from the 
MSSS on commanding activity 

• continuously verifying the validity of con- 
straints posed by the procedure 

Non-nominal situations are identified by the 
receival of alarms (e.g. TC verification failure 


alarms or Out Of Limit alarms) or by trend anal- 
ysis of telemetry parameters. At present the EOA 
system assists in processing alarms by: 

• investigating the cause of the alarm 

• distinguishing alarms requiring action from 
non-relevant or expected alarms 

• invoking and executing Contingency Recov- 
ery Procedures (CRP’s) 

Situations requiring complex diagnosis before 
execution of a CRP or requiring actions which are 
not implemented in the form of an existing CRP, 
are considered in the last phase of the project, 
and is therefore not yet demonstrated by the pro- 
totype. 

FCP’s and CRP’s are both special cases of 
Flight Procedures. EGA supports the execution 
of procedures in general, and therefore the execu- 
tion of CRP’s are supported in the same way as 
execution of FCP’s. 

The EOA utilizes the knowledge of experts to 
perform procedures, and to reason about prob- 
lems in much the same way as is done by the ex- 
perts themselves. It has the ability to explain its 
reasoning, and incrementally acquire new knowl- 
edge. 

Additionally, the EGA is more flexible than 
conventional software, e.g. it responds oppor- 
tunistically to incoming data, or situations, and 
modifies its behaviour under varying conditions. 
As an example, procedures have to cope with the 
exigences of the current situation, or cope with 
reconfiguration or modification of the units con- 
sidered. 

The EOA provides a number of expert func- 
tions integrated within the system which can be 
organized along three axis: 

• procedure generation, 

• spacecraft state monitoring, 

• execution scheduling. 

These types of functions are described in more 
detail in Section 5, and can be summarised as fol- 
lows: 

Concerning 'procedure generation , the functions 
range from interpretation and execution of already 
existing procedures to generation of new proce- 
dures. 

With spacecraft state monitoring , functions 
range from conventional verification of patterns 
of parameters to complex failure diagnosis. 
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Execution scheduling func tions are initially ded- 
icated to controlling the timing of procedure exe- 
cution. However, it happens that procedures com- 
pete for execution and the system provides func- 
tions to arbitrate conflicts. 

Additionally EOA has facilities for supporting 
the spacecraft engineer in editing and maintaining 
the different types of knowledge in the knowledge 
bases. In particular, a syntax driven Flight Pro- 
cedure editor has been developed, in addition to 
standard knowledge maintenance facilities. 

3.2 System Architecture 

The EOA system communicates with two external 
entities: the user and the MSSS. 

The EOA system runs on an independent SUN 
workstation and communicates with the MSSS 
system via a X.25 communication link. It is im- 
plemented in the programming language Common 
LISP using the expert system shell KEE. How- 
ever, in order to ensure proper speed in perfor- 
mance, and to have proper access to the operating 
system, parts of the system taking care of com- 
munication with the MSSS and the user is imple- 
mented directly in the C programming language. 

The architecture has been designed with special 
attention to the fact that the EOA is integrated in 
a real-time environment, and that it must always 
be able to respond to the MSSS (eg. to process 
alarms). Furthermore an aim of the architectural 
design has been to construct an open ended and 
modular architecture, thereby supporting mainte- 
nance and future extensions. 

The result is a multiprocess architecture, con- 
sisting of a number of interacting systems, com- 
municating through a common protocol. The ar- 
chitecture is outlined in Figure 1. 

The EOA MANAGER takes care of the overall 
scheduling in the system, and the internal com- 
munication protocol. 

The Dialogue System is a monitor for the User 
Interface. This interface is described in the next 
section. 

Receiving, buffering and parsing of information 
from the MSSS, and formatting and sending mes- 
sages to the MSSS is handled by the External Sys- 
tems Interface. The TM/TC System is a monitor 
for the External Systems Interface. 

All the system Knowledge Bases have a com- 
mon interface, called the KB Methods, through 
which all accesses are made , The Knowledge Base 
Management System constitutes a monitor for the 
Knowledge Bases of the EOA, and contains func- 


tions for retrieving, inferring and updating knowl- 
edge. 

The Flight Procedure Execution System is the 
central system supervising and controlling the ex- 
ecution of procedures (FCP’s and CRP’s), inter- 
preting TM’s, validating and verifying TC’s etc. 

The Knowledge Maintenance System monitors 
the execution of the EOA, the user and MSSS in- 
teractions, and controls the consistency, complete- 
ness and feasibility of the EOA knowledge. The 
system propose updates of the knowledge and also 
evaluate updates proposed by the user. 

The Fast Response Recovery System takes over 
control in case of a non-nominal situation and per- 
forms alarm processing, and selection of CRP’s to 
invoke in cases where this can be done without 
complex diagnosis. 

In other non-nominal situations control may 
be transferred to an Advanced Reasoning System 
which, in close interaction with the user, performs 
complex diagnosis, and generates new procedures 
if necessary. As indicated in Figure 1 this system 
is not implemented in the current prototype so 
far. 

3.3 User Interface 

There are two main categories of users: spacecraft 
operators who control the daily operations of the 
spacecraft, and spacecraft engineers who are the 
experts knowing about the design of the space- 
craft. Each has a different pattern of communica- 
tion with the system. 

The User interface utilizes “state of the art” 
Man Machine Interface (MMI) techniques, includ- 
ing mouse, windowing, and pop-up menus in the 
user interaction. It has been designed using the 
powerful facilities of KEE. 

Figure 2 shows the basic layout of the EOA 
screen used for daily operations. It is divided into 
two separate areas, the System Area and the Pro- 
cedures Area. 

In the System Area all system level information 
and EOA operational information is displayed, 
and most user dialogue takes place here. In 
the basic layout, windows for querying the user 
(Prompt Window), for logging the operations and 
tests are also as default placed in the system area. 
However, these can be moved around by the user. 
The system area contains an array of buttons 
which are used to select system functions. 

In the Procedures Area the active procedures 
are displayed, and progress of the procedures is 
monitored. The area contains, for each active 
procedure a group of windows for the execution 
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Figure 1: Architecture of the EOA System 
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Figure 2: EOA Prototype System Screen Layout for Daily Operation 
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and control of that procedure. The procedure 
is displayed both textually in the Text window, 
and graphically as a flow diagram in the Proce- 
dure Execution Path window, where the part of the 
procedure already executed appears in highlighted 
form. There are also windows displaying the in- 
formation to and from the satellite (T C Stack and 
TM Display) window. For each procedure, there 
is an array of buttons for the control of the pro- 
cedure (authorize an action, skip a step, abort 
procedure, ...). 

Spacecraft engineers can use another EOA 
screen 2 to display and edit knowledge bases. It in- 
cludes a syntax driven editor permitting to write 
procedures. 

4 KNOWLEDGE REPRE- 
SENTATION 

The knowledge structure in the EOA has been 
organized so as to provide satisfactory solutions 
to the specific problems of procedure generation 
and execution. 

Procedures can be structured as sequences of 
steps. Each step implements a piece of procedure, 
and contains tests, actions (TC uplink, display 
message, .;.), conditional statements, go-to state- 
ments, iterations and transfers to other pieces of 
informations (e.g. other procedures). 

With conventional sequential programming 
techniques, the order of task execution within 
a program is entirely determined by the control 
structure of the code. Conventional programs are 
rather non-responsive to unanticipated situations, 
and lack flexibility. The EOA approach is to de- 
scribe each procedure or part of procedure as a 
set of schematic instructions (called scripts ) which 
are expanded (or interpreted) in the context of the 
execution. Each schematic instruction describes a 
goal, that the system will try to achieve in execut- 
ing the procedure.* An inference mechanism pro- 
vides a means for directly using the knowledge in 
the system to reach the desired operational goals, 
through choices of applicable knowledge. 

The declarative semantics which is used to- 
gether with the inference mechanism provides a 
good flexibility, allows fdr incremental changes to 
the system, and explanatory capabilities. 

Another issue which comes with conventional 
programming techniques is that pieces of code 
(e.g. subroutines) are named or labelled with 

2 by “EOA screen” we mean a specific layout of the 
workstation display 


arbitrary names which have to be unique. The 
drawback of this approach is that the link be- 
tween a piece of code and its functionality may 
be lost, hereby loosing software engineering and 
explanatory possibilities. In the EOA, each set of 
schematic instructions (or scripts) is attached to 
a name which specifies its goal. This goal is used 
by the inference mechanism so as to achieve the 
desired operational goals. Therefore, the EOA is 
goal-oriented . 

However, attaching a goal to a script is not suffi- 
cient , There may indeed be many ways to achieve 
a goal, each way being applicable in a specific con- 
text. A context is a set of facts which represent 
the state of the world, as it is affected by the 
procedure. With conventional programming tech- 
niques, it is only the control structure that allows 
to call a subroutine or another. With the EOA, 
each script has attached a goal but also a context 
specifier, which specifies in which circumstances 
the considered script can be used to achieve the 
attached goal. During procedure execution, it is 
the inference engine which identifies for an invoked 
goal, which script is applicable with respect to the 
current execution context. 

A context specifier is defined as a list of vari- 
ables with desired values. This implementation 
paradigm has been chosen so as to achieve a dou- 
ble purpose. As explained above, the aim is to 
provide a deterministic and unambiguous defini- 
tion of the context where the script is applicable. 
The list of pairs (variables desired ..values) repre- 
sent the facts which have to be true in the context 
of the execution. The context specifier may also 
be needed to query supplementary informations, 
as needed for the execution of the script. It is pos- 
sible in the script to specify the context for a call 
to a goal, or to modify the current context. Each 
context instruction is lexically scoped. Therefore, 
the EOA is also context-oriented . 

The execution of a piece of procedure described 
by a script calls for many oilier informations 
which are explicitly or also at times implicitly 
stated in a conventional procedure. These infor- 
mations have been formalized using the Theory 
of Plans ([Wil83]). The selected types of informa- 
tions are: 

• pre-execution checks , which have to be true 
before continuing the execution of the piece 
of procedure, 

• execution constraints , which have to remain 
true throughout the execution of the piece of 
procedure, 
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• the script itself ] which describes the checks 
or actions to be performed, and goals to be 
achieved with this piece of procedure, 

• post- execution checks , which have to be true 
immediately after the execution of the piece 
of procedure, 

• post- execution constraints , which have to re- 
main true after the execution of the piece of 
procedure, until they are unset by another 
piece of information. 

It appears then that many informations are at- 
tached to a given goal. In the EOA, the chosen 
implementation paradigm is to group all these in- 
formations into an object, whose facets will hold 
the various types of informations (Figure 3). 

As previously explained, several procedures 
may exist, allowing the achievement of a given 
goal in different contexts. These procedures may 
share common pieces of informations. Therefore, 
they are grouped in a hierarchy, where the parent 
procedure holds the the common pieces of infor- 
mation, including in particular the goal specifi- 
cation. The common informations are inherited 
down the hierarchy, until overwritten by local in- 
formation specific of a procedure or sub-hierarchy 
of procedures. Procedures are thus implemented 
as a hierarchical library of objects. 

The objective of the knowledge acquisition pro- 
cess is then to feed in each object complete expert 
knowledge, so that each object contains necessary 
and sufficient information for object selection and 
object execution. The sources of knowledge can be 
spacecraft design (e.g. for the various sub-systems 
of the spacecraft), or operational experience (e.g. 
general technical expertise of mission controllers) . 

To conclude with, the EOA is object oriented , 
in order to provide an efficient and convenient im- 
plementation for procedural expert knowledge. 

The EOA project share common goals with 
PRS ([Geo85],[Geo86]); namely it aims at build- 
ing a system that explicitly represents and reasons 
about procedural knowledge. The EOA approach 
is less general in the sense that control knowledge 
is not represented as explicitly as in PRS (e.g. 
the fact that TC failure alarms have priority over 
COL alarms must be modified by the implemen- 
tor). On the other hand the EOA language is 
richer. It permits to implement complex proce- 
dures with iterations and conditionals that look 
quite similar to real procedures. This facilitates 
manual validation of procedures. 


5 EXECUTION OF 

FLIGHT PROCEDURES 

This section illustrates how the knowledge imple- 
mented in the EOA is used for the execution of 
flight procedures. 

5.1 Procedure generation 

The system is used in a goal-oriented way. The 
user can enter a goal corresponding to a procedure 
or a step. The user is prompted if the specified 
goal does not match unambiguously one of the 
goals known by the system. 

When one goal is unambiguously identified, its 
applicability with respect to the current context is 
examined by the system. To do so, the system col- 
lects the object or hierarchy of objects which are 
able to perform the specified goal. Then, using 
the context specifier of each object, it tries to find 
at least one applicable object. The introduction of 
required information is done through interaction 
with the user, when information is not available in 
the system. If no object is found applicable, the 
system leaves the procedure execution mode and 
enters a procedure generation mode (to be devel- 
oped) where the system tries to construct a small 
procedure in order to set the world in a config- 
uration compatible with the specified goal. This 
is typically a planning process, with chaining of 
"operators” from one state to another. 

When a convenient object has been found to 
achieve the initial goal, its execution is initiated. 
The instructions described in Chapter 4 as pre- 
execution checks are initially performed. Execu- 
tion constraints are asserted and checked period- 
ically. The most important part of the execution 
is with the interpretation of the script. As men- 
tioned in Chapter 4, the script contains a set of 
instructions, such as actions (Telecommand up- 
link), checks (e.g. Telemetry Values), conditional 
statements, and call to other goals. Finally, post- 
execution check instructions are performed and 
post-execution constraints are asserted. 

In the process of cascading the initial goal into 
sub-goals specified in the script, the inference en- 
gine will recursively try to achieve the sub-goals. 
Each sub-goal can be called within a specific con- 
text, by locally amending some aspects of the cur- 
rent context. The initial goal will be considered 
as achieved as soon as all goals in the cascade of 
sub-goals are achieved. Achieving each sub-goal is 
done sequentially, respecting the procedural order 
described in the script. 
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Figure 3: EOA prototype system: Object facets 


An interesting feature is that the inference en- 
gine which is used to perform script instructions 
and cascade into sub-goals is based on an in- 
terpreter which is interrupt driven. Whenever 
the execution of instructions finds some reason to 
stop (e.g. wait for the right time or detection of 
anomaly), the code which is returned contains: 

• the context of the current execution, 

• the continuation of the execution, i.e. all the 
instructions which are to be executed as soon 
as the execution resumes. 

This is very convenient so as to explain what 
has been done and what remains to be done. 

When something goes wrong in the execution 
process, the system analyses the cause of the pro- 
cedure interruption in order to assess which mea- 
sures are needed to enable the resumption of the 
execution. 

As an example, when the system is waiting for 
the right time to initiate some action, no special 
action has to be performed. In the same way, 
when some telecommand has just been uplinked, 
and the corresponding telemetry check fails, noth- 
ing has to be done since at least one telemetry 
flow has to come down before the telemetry ac- 
tually appears as changed. On the other hand, 
if the telemetry check still fails after reception of 
several telemetry flows, the system reacts to this 


anomaly. This may result in uplinking again the 
Telecommand, or entering a complex diagnostic 
process. In the same way, when no object is found 
applicable for the achievement of a given goal, the 
system may ask the user to confirm the goal spec- 
ification together with the call context, and later 
on, initiate the construction of an appropriate new 
procedure. 

5.2 Spacecraft State Monitoring 

In a first phase, the control of the spacecraft state 
is done through the verification of the values of 
a large set of telemetries, generally grouped into 
Analogical Displays in the MSSS workstations. 
The EOA does not copy all the TM verification 
carried out by the MSSS, but focus on verifying 
selected parameters in order to assess the progress 
of procedures. The basic reaction to some unex- 
pected telemetry value is described in Section 6. 

5.3 Execution Scheduling 

The execution of procedures may be time driven. 
For example, the performance of eclipse opera- 
tions has to comply with a precise timing. The 
EOA provides functions for time monitoring. 

Another type of scheduling problem exists when 
time constrained procedures compete for execu- 
tion. Another example is a contingency recovery 
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procedure (CRP) being initiated while a Flight 
Control Procedure (FCP) is being performed. 
The EO A could include functions to manage earli- 
est start times (ESD) and latest completion dates 
(LCD), and implements heuristics to prioritize a 
procedure against another. 

When performing procedure generation, the 
EO A may also need to manage scheduling aspects 
in order to verify the feasibility of the generated 
procedures. 

6 ALARM PROCESSING 

A key skill for spacecraft control is the ability to 
react quickly to any kind of alarm from the MSSS. 
Reactions range from simple actions like calling an 
expert for help, to important decisions like ignor- 
ing an alarm or choosing and executing a contin- 
gency recovery procedure. For each possible alarm 
the spacecraft controller can find in the FOP a se- 
quence of actions that can be done. Since these 
actions have been written conservatively they of- 
ten lead to a call for help. 

One goal of the EOA is to provide assistance to 
increase reliability, speed and scope of day alarm 
processing. The implemented prototype deals 
with alarm combinations that have been foreseen 
in advance and can be treated by existing emer- 
gency procedures. 

In compliance with the philosophy of the 
project it was not attempted to design new alarm 
mechanisms but to provide assistance to users of 
the existing control center. The EOA must deal 
with all the alarms of the MSSS. Nevertheless it 
is also possible to implement new kinds of alarms. 
This can be done by one or several procedures 
running permanently to perform a trend analysis 
for instance. 

The MSSS generates two kinds of alarms: 

1. TC verification failures when something goes 
wrong in a TC uplink, and 

2. Out Of Limit (00L) alarms when some pa- 
rameters goes outside some limits defined dy- 
namically on the MSSS or have inconsistent 
values. 

Thanks to the multiprocess capability of the 
EOA, alarms are processed as soon as they arrive 
from the MSSS without interrupting procedures. 
One important problem is to know which alarm to 
focus on since an alarm rarely occurs alone. For 
this the EOA uses different kinds of knowledge: 
priority number on OOLs, alarm prediction in- 
cluded in procedures, mode definitions which can 


explain that an alarm has been caused by another 
one. In any case the user can focus on the alarm 
of his choice and can discard non relevant alarms. 

Once an alarm has been selected a set of rules 
are evaluated to generate a list of all the proce- 
dures that can be applied. Each procedure can 
have such a rule, written in the EOA language, to 
indicate whether it is appropriate to enter the pro- 
cedure. If the rules have been well written at most 
one procedure will be applicable. In the other case 
the user has to arbitrate which procedure to start 
or call for help. 

The alarm processing scheme described here 
can be improved in many ways. One of them be- 
ing the interface with a diagnostics expert system 
such as DIAMS ([Haz88]) that incorporate space- 
craft design knowledge for those situations that 
require a sophisticated diagnostics method that 
cannot be implemented conveniently as a proce- 
dure. 

Another direction for improvement consists in 
developing a more sophisticated priority scheme. 
When alarms occur during the execution of the 
FCP the EOA may have to start a CRP in paral- 
lel. The default rule is to give priorities to CRP’s 
over FCP’s. Clearly this can be improved since 
a FCP may have crucial hanging constraints (e.g. 
put a component off). One solution would be to 
acquire priority numbers attached to each steps 
of procedures from experts. A more ambitious 
scheme would be to infer these priorities from de- 
sign and operational knowledge. 

7 CONCLUSION 

A large part of the functions described in this 
paper have already been implemented leading to 
a prototype that covers assistance to spacecraft 
controllers for normal daily operations and simple 
non-nominal situations. Obviously there is room 
for a lot of improvements and extensions but the 
EOA has already shown interesting results. 

Eight procedures that are quite representative 
from the MARECS-B2 FOP have been imple- 
mented including station keeping, eclipse opera- 
tions, recovery from payload switch-off, and recov- 
ery from automatic reconfiguration. The syntax 
driven procedure editor and the knowledge base 
inspectors together with the methodology for pro- 
cedure generation should permit to extend this 
set. 

A flexible multiprocess architecture for real 
time expert system makes possible the commu- 
nication and integration with the ESOC MSSS. 
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Evaluation of the EO A is carried out in close coop- 
eration with potential users, namely the operators 
and spacecraft engineers working at ESOC. There 
are good hopes that the EO A will demonstrate the 
feasibility and utility of knowledge based operator 
assistance for spacecraft control. 
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